fix(release): self-heal the release-please "untagged, merged" abort - #7149

Summary

Root cause traced as far as possible into release-please's own source: createReleases() (the step that actually tags a merged Release PR) sometimes finds nothing to tag, and createPullRequests() then aborts every subsequent run without ever completing the tag. Confirmed live across two separate linked-versions release cycles this session (#7127, #7133), both requiring a manual dispatch of each publish-*.yml workflow plus manually flipping the merged PR's autorelease: pending label. This matches several long-open, unresolved upstream issues (googleapis/release-please#1946, #1444, #1406 -- same exact message), so it isn't something fixable from this repo's config alone.

Adds a reconcile-stale-releases job that runs after every release-please attempt, independent of its outputs (which are unreliable exactly when this bug is in play):

• Compares each package's committed package.json version against what's actually live on npm, and dispatches that package's publish workflow whenever they disagree -- the same "bare manual dispatch" human-override path each publish-*.yml already documents, just triggered automatically instead of by a human noticing red CI on an unrelated PR days later.
• Engine publishes first and is awaited before mcp/miner (they carry a real runtime dependency on it, and their own isolated pack/smoke-test resolves @loopover/engine from the real npm registry, so it fails with ETARGET if engine hasn't actually published yet -- confirmed live when I first tried dispatching all three in parallel).
• Once every package is confirmed live, flips any merged PR still carrying autorelease: pending to autorelease: tagged, unsticking release-please's own tracking for its next run.

Real npm publishes still go through the same environment: release required-reviewer gate as always -- this doesn't remove that security control, it just eliminates the diagnostic/dispatch/label-cleanup toil around it.

Side effect I verified is safe and beneficial: running the version-comparison logic locally against this repo's real current state found one ancient, silently-stuck instance of the exact same bug (engine v1.0.0's Release PR, still autorelease: pending since long before this session) -- the new job's cleanup step will resolve that too.

Test plan

• npm run actionlint -- clean
• Extracted both run: scripts and ran bash -n on each -- syntax valid
• Ran the actual version-comparison script for real against this repo's live state: correctly identified all 4 packages as already in sync and dispatched nothing (safe to execute as a real validation since nothing was out of sync)
• Workflow-only change; not measured by Codecov. Real verification: the next release-please abort should self-resolve within this same job's run instead of needing manual intervention.